Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments
Jay Pipes jaypi...@gmail.com 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 Nagios-as-a-Service for tenants either. for the same use cases as how a teanant would want use the already established cloudwatch/RAX monitoring on private OpenStack. They would just want to do a simple REST call to monitor their server : curl -X POST http://api/ -d 'monitor my server/port/etc/' and not having to install/configure/setup a Nagios or whatever monitoring server Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible
Victor Stinner vstin...@redhat.com 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 to run 2to3 to see modified lines. In Swift, Alex has installed this tox.ini target to detect those : https://github.com/openstack/swift/blob/master/tox.ini#L38 may be a good idea to generalize. Cheers, Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 to know how doea it store it there?is there any algorithm for it? this should be documented here : http://docs.openstack.org/developer/swift/overview_ring.html Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 nice, I think it would be nice down the line if we could have direct interaction from ansible with the docker containers and not having to call docker-compose from ansible playbooks to allow more flexibility. Monty Taylor mord...@inaugust.com writes: If you haven't already, I'd connect with the os-ansible-deployment folks, who are deploying openstack with ansible into containers. I believe they are currently doing production deploys, so you may find working with them rather than duplicating more productive. As far as I know os-ansible-deployment is doing straight integration but that's based on LXC and not using packages (and don't seem to respect the one daemon/process by container aspect) but even tho I am sure there is a lot of things that they have solved there that could potentially be shared with kola. Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Re: Questions about kolla
On Mon, Mar 30, 2015 at 3:42 PM, Steven Dake (stdake) std...@cisco.com 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 the OpenStack services. it is and available here, https://github.com/ceph/ceph-docker (Seb in Cc of this email is the one who have been working on this) Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 cor...@inaugust.com 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 run with tox -e or a script launched by git-review as pre submit to git ? Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 mord...@inaugust.com 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_scripts thing[1] to read tox.ini or other shipped with the project file to run the pre-review script from it. Chmouel PS: I haven't looked at yapf so i have not much opinion about it. [1] https://git.openstack.org/cgit/openstack-infra/git-review/tree/git_review/cmd.py?h=master#n229 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 extensively fig back in the days for an internal project of mine and quickly come to its limitations with regard to caching and redeployment (was keeping having to do fig ps -q|xargs -r docker stop || true ) Cheers, Chmouel On Sun, Mar 22, 2015 at 4:50 PM, Steven Dake (stdake) std...@cisco.com wrote: FenghuaFeng, Ccing openstack-dev 1. Kubernetes doesn’t offer a control or integration point. We have that now with docker-compose. 2. Kubernetes doesn’t offer super privileged containers. We need that in order to operate an OpenStack environment. Regards -steve From: 449171342 449171...@qq.com Date: Sunday, March 22, 2015 at 1:47 AM To: Steven Dake std...@cisco.com Subject: Why we didn't use k8s in kolla? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg
On Tue, Mar 24, 2015 at 11:40 AM, Flavio Percoco fla...@redhat.com 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 example and I think in a container like environement we would want to have it using automatically the environnement variables but those can be different behavior by different stevesdore drivers if we needed. Cheers, Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 quickly override the default keys in a central point. There is multiple advantage to use that method not just for containers but as well to avoid issues when orchestrating an openstack deployment. I have heard arguments that this should be the job of an ansible/puppet/chef tool and while I completely agree I just don't think it has to write to files the tool would just write to the etcd database. I have quickly came up with a quick and dirty POC on oslo.cfg here : https://github.com/chmouel/oslo.config/commit/01ee54dd5219b1434eaac422055b58e77694d89f and the demo : https://gist.github.com/chmouel/05fb715f96344161268c What others thinks about it ? I believe if we wanted to do that we would have to add a stevesdor based modular backend support directly to oslo.cfg first and have an etcd backend implemented. Chmouel PS: I am using etcd here cause it's easy and fancy but this could be any backends like a DB/NoSQL/Swift or whatever if we wanted __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 operate each as an independent cloud. I think this is a really good idea, and will do a lot for OpenStack. Here's what we would get out of it: Pretty cool! thanks to HP for providing this. If that's possible (with HP and if the infra wants to allow that) it would be nice to allow a dev to login into the failing vm for investigation. Cheers, Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Deprecation of Eventlet deployment in Kilo (Removal for M-release)
Morgan Fainberg morgan.fainb...@gmail.com 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 deployment under Apache as the default advised way, will look forward for others to follow (if it make sense). Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Pluggable Auth for clients and where should it go
On Wed, Feb 18, 2015 at 8:54 PM, Dean Troyer dtro...@gmail.com 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. It is no longer that...and maybe not even the right example of how to use auth plugins even though jamielennox did most of that work. and FYI jamie has a serie of excellent articles about keystone's pluggable auth on his blog: http://www.jamielennox.net/ Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 berra...@redhat.com 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 be any records available publicly. Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
Jaume Devesa devv...@gmail.com 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. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? as you stated I don't think there is a clear advantage or disadvantage but IMO having too many repositories is not very user friendly and I would recommend to have the plugin directly in the repo. For things like glusterfs which is not a native openstack project it makes sense that the plugin is hosted externally of the project. Chmouel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
Sean Dague s...@dague.net 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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-announce] [keystonemiddleware] keystonemiddlware release 1.3.0
On Thu, Dec 18, 2014 at 8:25 PM, Morgan Fainberg morgan.fainb...@gmail.com 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 your py3 based wsgi service. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] proposed rules drop for 1.0
On Tue, Dec 9, 2014 at 12:39 PM, Sean Dague s...@dague.net 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 sending the review but I guess it's not a common usage. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 extras plugins/features in the default devstack core because it's way more convenient for their users. The policy has been mostly (and correct me if I am wrong) that things which are not tested in the gates cannot be in core devstack. What about having a plugin structure for devstack assuming a standard directory structures which devstack would download and use automatically. For the implemention I was thinking about something like this in our local.conf : enabled_services blah_feature: https://git.openstack.org/stackforge/devstack-plugin-feature and that repo gets downloaded and used automatically. I understand that it is just a shortcut since curl -O https://git.openstack.org/stackforge/devstack-plugin-feature/devstack_plugin.sh in extras.d would work as well but maybe that would make people more confortable not having to be in core devstack and tell their users easily how to test a feature/driver with Devstack? Cheers, Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] external plugin support for Devstack
On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague s...@dague.net 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 directory before running. +1 you are taking this way forward and it would look even better, even for official projects managing their own devstack installation would be great! (kinda like we are heading with functional tests) Which would let projects keep their devstack support local, make it easy to gate their project on it, give those projects the ability to make local fixes if something in devstack broke them. I think that in general providing this kind of functionality is goodness. We should probably get the details hammered out though to support local running and automated testing coherently. We don't seem to have any specs repo for devstack where this could be worked on ? Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night
Hello, On Fri, Nov 21, 2014 at 10:10 PM, Mike Bayer mba...@redhat.com 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-batch-migrations-for-sqlite-and-other-databases a Great news about the sqlite support, I think that link to the documentation doesn't work tho. Thanks, Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 angelo.matara...@dektech.com.au wrote: Hi all, sometimes I use devstack (in a VM with Ubuntu installed) and I perform ./unstack command to reset my environment. When I perform rejoin-stack.sh keystone endpoint doesn't work. Following http://www.gossamer-threads.com/lists/openstack/dev/41939 suggestion I checked /etc/apache2/sites-enabled and symbolic link to ../sites-available/keystone.conf and doesn't exist. If I recreate the symbolic link keystone works.. what is the correct workflow after I have performed ./unstack.sh Should I perform ./stack.sh or this is a bug? Cheers, Angelo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 prevent excessive data growth from old sessions. 2) SQLite is far worse to go into production with than cookie-based sessions (which are far from perfect). The more we can do to ensure people don’t make that mistake, the better. memcache can be distributed (so usable in HA) and has far better performances then db sessions. Why not use memcache by default? I guess for the simple reason that if you restart your memcache you loose all the sessions? Chmouel Just a suggestion. -- Yves-Gwenaël Bourhis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Travels tips for the Paris summit
On Wed, Oct 15, 2014 at 10:25 AM, Thierry Carrez thie...@openstack.org 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 are saying that this is the best place in paris for veggie burgers[1]: http://www.eastsideburgers.fr/en Chmouel [1] caveat may be bordeline parisian hippsterish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 2 Minute tokens
On Wed, Oct 1, 2014 at 3:47 AM, Adam Young ayo...@redhat.com 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.com/cloudwatt/swiftpolicy.git. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Kolla Blueprints
On Tue, Sep 30, 2014 at 6:41 PM, Steven Dake sd...@redhat.com 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 on something, this hsould help to prevent duplicate work :) As I understand in the current implementations[1] the containers are configured with a mix of shell scripts using crudini and other shell command. Is it the way to configure the containers? and is a deployment tool like Ansible (or others) is something that is planned to be used in the future? Chmouel [1] from https://github.com/jlabocki/superhappyfunshow/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. Probability depends on time gap between ops #1 and #2: the smaller the gap, the higher is probability (less time to sync). Also it depends on Swift installation size: the bigger is installation, the higher is probability (bigger 'space' for inconsistency). eventual consistency will only affect container listing and I don't think there is a need for container listing in that driver. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 server with an old copy comes back into the fray and you read before replication sorts it out, or read a old version of a key you deleted yeah sure thanks for clarifying but from my understanding all tokens are new keys/object there is not overwriting going on, Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Diagnosing problems with containers
On Fri, Sep 26, 2014 at 4:29 PM, Lars Kellogg-Stedman l...@redhat.com 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 cl...@fewbar.com 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 to manage the containers. I was exactly thinking about the same and looking at the code here : https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/client/request.go#L263 it seems to use some basic HTTP auth which should be enough with the REMOTE_USER/apache feature of keystone : http://docs.openstack.org/developer/keystone/external-auth.html#using-httpd-authentication but if we want to have proper full integration with OpenStack we would probably at some point want to teach modularity and a keystone plugin to give to k8 Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 sd...@redhat.com 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 project separate from the TripleO/Deployment program code base Congratulations this sounds promising! If I understand correctly reading your POC there is two part to Kolla the docker images repository of openstack services and a future service (or kubernetes plugin?[1]) driving the communication and deployments to kubernetes. I think making sure that we separate the two would be nice to have, since if we can plug those images within devstack, thanks to the abstraction of how we run processes that was introduced by Dean (http://git.io/Px1nMg) perhaps that would be a nice way to make devstack more robust and have a nice side effect to have a pretty good testing for those docker images. Chmouel [1] CAVEAT: I don't know very well kubernetes, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [All] API standards working group
On Wed, Sep 24, 2014 at 12:18 AM, Jay Pipes jaypi...@gmail.com 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.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 don...@stufft.io 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 Python 2.x, or let them be optional and if people want to disable TLS compression in those versions they can install those versions themselves. we have that issue as well for swiftclient, see the great write-up from stuart here : https://answers.launchpad.net/swift/+question/196920 just removing it this and let hope that users uses bleeding edge python (which they don't) is not going to work for us. and the pyOpenSSL way is very unfriendly to the end-user as well. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)
Ian Cordasco ian.corda...@rackspace.com 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 using httplib which didn't have SSL verification. There is a old wiki page about it here https://wiki.openstack.org/wiki/SecureClientConnections Slightly off-topic, speaking about requests and OpenStack client, it would be nice to have Expect/100-Continue feature tackled for glanceclient and swiftclient : https://github.com/kennethreitz/requests/issues/713 Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 don...@stufft.io 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. I think Thomas was speaking in the context of how OpenStack is used by the end user and that probably the point of debate here, requests ships libraries inside to make it easy for users that doen't use Linux distro packages, when in OpenStack (or at least in prod) packagers are something we generally very much care about. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST
Sean Dague s...@dague.net 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 that can be found to please everyone. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] adding RSS feeds to specs repositories
Doug Hellmann d...@doughellmann.com 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 feeds to planet.openstack.org, but given the length of some of the specs I’m less sure of that. Instead, now I think it would be better to publicize the list of URLs for people who want to subscribe to some or all of them separately. After some of them land and we have a few feeds published, I will find a good place to do that. what about a http://planet.specs.openstack.org, i think that could be neat and would give the list of the individual feeds if someone don't want to follow the planet ones. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)
On Tue, Sep 9, 2014 at 12:24 AM, Joe Gordon joe.gord...@gmail.com 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 killed devstack even before the tempest runs. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Review change to nova api pretty please?
On Sat, Aug 30, 2014 at 11:28 AM, Alex Leonhardt aleonhardt...@gmail.com 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://wiki.openstack.org/wiki/MailingListEtiquette and I have added the Review request section there. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 fu...@yuggoth.org 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 that particular job. yes indeed and that's super useful, but it was just a bit too many clicks for me on the review (and to look in the doc for the spec that was proposed in the patchset). Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 here : https://gist.github.com/chmouel/1db66bd76e7fcbc7a13e (need gerritlib/requests/docutils and rst2pdf if the pdf generation is chosen) Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On Wed, Aug 13, 2014 at 3:05 PM, James E. Blair cor...@inaugust.com 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 useful one litle suggestions for the folk that knows how to do that if that's possible to do is to sort between the voting and the non-voting so we can easily spot which one are worthwhile to look at or not. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On Wed, Aug 13, 2014 at 6:27 PM, James E. Blair cor...@inaugust.com 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 and experimental queues) to develop new jobs without creating noise. If there is a third-party CI system reporting non-voting jobs, um, I don't know what that means. If it bothers you, you might ask the third-party CI system to disable them and if they don't, then ask us to disable the third-party CI system. I didn't meant that they were not worthwhile to look at I was just thinking it could be useful to sort them so we can easily identify from a UI perspective which one was voting or not. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Core team proposals
On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer dtro...@gmail.com 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.org/cgi-bin/mailman/listinfo/openstack-dev
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: (pip._vendor.requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x37e4790, 'Connection to pypi.python.org timed out. (connect timeout=15)') I think this error message is pretty self explanatory Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 as experimental jobs. The idea here is that we'll actually be able to provide more configurations that are operating in a more traditional CI (post merge) context. People that are interested in keeping these bits functional can monitor those jobs and help with fixes when needed. The experimental jobs mean that if developers are concerned about the effect of a particular change on one of these configs, it's easy to request a pre-merge test run. In the near term we might imagine this would allow for things like ceph, mongodb, docker, and possibly very new libvirt to be validated in some way upstream. What about external CI ? is external CI would need to be post merge or still stay as is ? what would be the difference between external CI plugging on review changes and post CI merges? Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] REST API access to configuration options
On Tue, Jul 15, 2014 at 9:54 AM, Henry Nash hen...@linux.vnet.ibm.com 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 clients behavioural features. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 s...@dague.net 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 Wed, Jun 11, 2014 at 9:47 PM, Sean Dague s...@dague.net 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 the --debug option innefective right? Is it addressed in a different way in other clients? 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 Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah chmo...@enovance.com wrote: On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague s...@dague.net 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 the --debug option innefective right? Is it addressed in a different way in other clients? Anyway I have sent a patch for swiftclient for this in : https://review.openstack.org/#/c/99632/1 Personally I don't think I like much that SHA1 and i'd rather use the first 16 bytes of the token (like we did in swift server) 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 Thu, Jun 12, 2014 at 1:59 PM, Sean Dague s...@dague.net 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, but sure it would just make it a bit harder. Because everyone is running our servers at debug levels, it means the clients are going to be running debug level as well (yay python logging!), so this is something I don't think people realized was a huge issue. so maybe the issue is that those curl commands shows up in server log when they should only output when running swift/nova/etc/client --debug, right? Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Selecting more carefully our dependencies
On Thu, May 29, 2014 at 11:25 AM, Thomas Goirand z...@debian.org 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 bound to its own use cases. is it something that could be 'testable' from an external CI which would be in the requirements repo when there is a new library added? Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] storage policies merge plan
On Tue, May 27, 2014 at 10:02 AM, Hua ZZ Zhang zhu...@cn.ibm.com 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 practical, but I may be wrong. Chmouel. [image: Inactive hide details for John Dickinson ---2014-05-24 上午 06:27:13---John Dickinson m...@not.mn]John Dickinson ---2014-05-24 上午 06:27:13---John Dickinson m...@not.mn *John Dickinson m...@not.mn m...@not.mn* 2014-05-24 上午 06:27 Please respond to OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org To OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, openstack-operat...@lists.openstack.org cc Subject [openstack-dev] [Swift] storage policies merge plan We've been working for a long time on the feature/ec branch in the swift repo. It's now done and needs to be merged into master to be generally available. Here's how the integration is going to work: 1) The feature/ec branch will be refactored into a series of dependent reviewable patches 2) The patch chain will be proposed to master, and master will enter a freeze until the storage policy patches land 3) The first patch in the chain will be marked as -2 to plug the chain 4) The Swift community will review and approve all patches in the chain. 5) When all patches in the chain are approved, the first -2 will be removed and the whole chain will be sent to the CI system There are two things that I'll ask of you during this time. First, please commit time to reviewing the storage policy patches. Second, please do not deploy a version of Swift that is midway through the storage policy patch chain. I don't expect it to break anything, but it's a complicating factor best to be avoided. I will send out another email when the patch chain has been proposed to master and to announce the freeze. --John *(See attached file: signature.asc)* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 program name. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [swift] swiftclient functional tests gate for python-swiftclient
Hello, Now that the functional tests on swiftclient has been merged, what do you think about adding a job for it to actually test them against a devstack the same way we do in 'swift'? Thanks, Chmouel ---BeginMessage--- Jenkins has submitted this change and it was merged. Change subject: Add functional tests for python-swiftclient .. Add functional tests for python-swiftclient Coverage for swiftclient.client is 71% with these tests. Unit tests have been moved into another subdirectory to separate them from functional tests. Change-Id: Ib8c4d78f7169cee893f82906f6388a5b06c45602 --- A .functests M .unittests M swiftclient/exceptions.py A tests/functional/__init__.py A tests/functional/test_swiftclient.py A tests/sample.conf A tests/unit/__init__.py R tests/unit/test_command_helpers.py R 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: Verified -- To view, visit https://review.openstack.org/76355 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ib8c4d78f7169cee893f82906f6388a5b06c45602 Gerrit-PatchSet: 16 Gerrit-Project: openstack/python-swiftclient Gerrit-Branch: master Gerrit-Owner: Christian Schwede christian.schw...@enovance.com Gerrit-Reviewer: Alistair Coles alistair.co...@hp.com Gerrit-Reviewer: Chmouel Boudjnah chmo...@enovance.com Gerrit-Reviewer: Christian Schwede christian.schw...@enovance.com Gerrit-Reviewer: Donagh McCabe donagh.mcc...@hp.com Gerrit-Reviewer: Elastic Recheck Gerrit-Reviewer: Jenkins Gerrit-Reviewer: Luis de Bethencourt l...@debethencourt.com Gerrit-Reviewer: Samuel Merritt s...@swiftstack.com ---End Message--- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Rob Crittenden rcrit...@redhat.com 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 default, only Debian stable was still enabling it. The only feature that was left behind when we ported swiftclient to requests was the support of Expects (100-Continue) which is referenced upstream in this bug : https://github.com/kennethreitz/requests/issues/713 and it does not seem be trivial to add to requests Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Chmouel Boudjnah chmo...@enovance.com 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28
On Fri, Apr 25, 2014 at 6:10 PM, Zaro zaro0...@gmail.com 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 sure if there's a bug entered in our the issue tracker for this but you are welcome to create one. This probably would need more than just an update since currently git-review is using (AFAICT) the SSH api or perhaps a mix. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28
On Wed, Apr 23, 2014 at 12:40 AM, James E. Blair jebl...@openstack.orgwrote: 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 because I know that there is a pycharm/intelij plugin allowing to do gerrit reviews and it need the 'download-commands' gerrit plugin (http://is.gd/X9vIJ0) to work properly. Would love to be able to use that and to look over how to make an emacs mode out of it. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 the swift umbrella projects to handle such things and be able to include those policy module directly. I think we have enough swift core now that uses keystone everyday to sponsors the core review for that project. That mething i'd like to talk about with the folks at altanta even tho there is no session for it. Chmouel On Fri, Apr 25, 2014 at 11:25 AM, Nassim Babaci nassim.bab...@cloudwatt.com wrote: Hi everyone I would like to point out the bp https://blueprints.launchpad.net/swift/+spec/authorization-policy to may be have some early feedback from the community. I have submitted a first patch which I hope will serves as an example/base for discussion. Specially I was wondering what would be the best way to integrate the policy engine (or not) within swift. For now I have roughly adapted the policy engine found here ( https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py) and I removed all the unnecessary dependencies to modules like oslo.config, log, etc, and finally kept only the parts that deal with parsing and rule checking, but any advice in this (or more globally) would be highly appreciated. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] add support for ceph
On Fri, Apr 18, 2014 at 6:32 AM, Sean Dague s...@dague.net 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 : http://summit.openstack.org/cfp/details/379 Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 dou...@redhat.com wrote: Another +1 for using bash. Sounds like an easy win. On 15/04/14 12:31, Ghe Rivero wrote: +1 to use bash as the default shell. So far, all major distros use bash as the default one (except Debian which uses dash). An about rewriting the code in Python, I agree that shell is complicated for large programs, but writing anything command oriented in other than shell is a nightmare. But there are some parts that can benefit from that. Ghe Rivero On 04/15/2014 11:05 AM, Chris Jones wrote: Hi On 15 April 2014 09:14, Daniel P. Berrange berra...@redhat.com mailto:berra...@redhat.com wrote: I supose that rewriting the code to be in Python is out of the question ? IMHO shell is just a terrible language for doing any program that is remotely complicated (ie longer than 10 lines of I don't think it's out of the question - where something makes sense to switch to Python, that would seem like a worthwhile thing to be doing. I do think it's a different question though - we can quickly flip things from /bin/sh to /bin/bash without affecting their suitability for replacement with python. -- Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 add external apt sources for that. In devstack we are moving as well toward a nice and solid plugin system where people can hook externally and not needing to submit patch to add a feature that change the 'core' of devstack. I think the best way to go forward with this would be to : * Split the patch mentioned above to get the generic things bit in their own patch. i.e the storage file : https://review.openstack.org/#/c/65113/19/lib/storage and the create_disk (which would need to be used by lib/swift as well) : https://review.openstack.org/#/c/65113/19/functions * Get the existing drivers converted to that new storage format. * Adding new hooks to the plugin system to be able to do what we want for this: https://review.openstack.org/#/c/65113/19/lib/cinder and for injecting things in libvirt : https://review.openstack.org/#/c/65113/19/lib/nova Hopefully to have folks using devstack and ceph would just need to be : $ git clone devstack $ curl -O lib/storages/ceph http:///ceph_devstack (and maybe an another file for extras.d) am I missing a step ? Cheers, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 we had time/resources it would have been nice to quickly evaluate this (that blog article should help since pretty hands-on and detailled). Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][qa][all] Home of rendered specs
Thierry Carrez wrote: specs instead of docs because docs.openstack.org http://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. Great idea. Great idea indeed! that would allow them to be nicely indexed by the search engines! Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer tempest testing in gate
On Tue, Mar 18, 2014 at 5:21 PM, Sean Dague s...@dague.net 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 to cause us more pain, but what would be the plan of action? a non-voting gate for ceilometer as a start ? (if that's possible). Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 zait...@redhat.com 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-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 s...@dague.net 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:-http://github.com/fujita/swift3.git}
NOVNC_REPO=${NOVNC_REPO:-https://github.com/kanaka/noVNC.git}
RYU_REPO=${RYU_REPO:-https://github.com/osrg/ryu.git}
SPICE_REPO=${SPICE_REPO:-
http://anongit.freedesktop.org/git/spice/spice-html5.git}
I think all of these probably need to be removed from devstack. We
should be using release versions (preferably i
As for swift3 I have added an issue to the project requesting if this can
be moved to stackforge :
https://github.com/fujita/swift3/issues/62
fujita (the maint of swift3 in CC of this email) has commented that he's
been working on it.
This is going to be quite urgent for the next openstack release, Fujita do
you need help with this?
Regards,
Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 Fargetta marco.farge...@ct.infn.itwrote: Thanks Donagh, I will take a look to the ontainer-to-container synchronization to understand if it fits with my scenario. Cheers, Marco On Thu, Mar 13, 2014 at 03:28:03PM +, McCabe, Donagh wrote: Marco, The replication *inside* Swift is not intended to move data between two different Swift instances -- it's an internal data repair and rebalance mechanism. However, there is a different mechanism, called container-to-container synchronization that might be what you are looking for. It will sync two containers in different swift instances. The swift instances may be in different Keystone administrative domains -- the authentication is not based on Keystone. It does require that each swift instance be configured to recognise each other. However, this is only usable for low update rates. Regards, Donagh -Original Message- From: Fargetta Marco [mailto:marco.farge...@ct.infn.it] Sent: 13 March 2014 11:24 To: OpenStack Development Mailing List Subject: [openstack-dev] [swift] Replication multi cloud Hi all, we would use the replication mechanism in swift to replicate the data in two swift instances deployed in different clouds with different keystones and administrative domains. Is this possible with the current replication facilities or they should stay in the same cloud sharing the keystone? Cheers, Marco -- Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 gkot...@vmware.com wrote:
Hi,
The client gate seems to be broken with the following error:
2014-03-10 08:19:39.566
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_566
| Running setup.py install for python-mimeparse2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| 2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Found existing installation: setuptools 2.22014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Uninstalling setuptools:2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Successfully uninstalled setuptools2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| Running setup.py install for mccabe2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning:
Unknown distribution option: 'entry_points'2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| warnings.warn(msg)2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning:
Unknown distribution option: 'zip_safe'2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| warnings.warn(msg)2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
| usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts]
...]2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
|or: -c --help [cmd1 cmd2 ...]2014-03-10 08:19:39.567
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
|or: -c --help-commands2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
|or: -c cmd --help2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| 2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| error: option --single-version-externally-managed not
recognized2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| Complete output from command
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/bin/pypy -c
import setuptools,
tokenize;__file__='/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/build/mccabe/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/tmp.l53ekBaPmF/pip-5i1oDp-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/include/site/python2.7:2014-03-10
08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning:
Unknown distribution option: 'entry_points'2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| 2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| warnings.warn(msg)2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| 2014-03-10 08:19:39.568
http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
| /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267:
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 c...@ecbaldwin.net 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 Jenkins messages. Human reviews are left in blue.
javascript:(function(){
list = document.querySelectorAll('td.GJEA35ODGC');
for(i in list) {
title = list[i];
if(! title.innerHTML) { continue; }
text = title.nextSibling;
if (text.innerHTML.search('Build failed') 0) {
title.style.color='red'
} else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') =
0) {
title.style.color='#66'
} else {
title.style.color='blue'
}
}
})()
Carl
On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
I wrote an bookmarklet for neutron gerrit review.
This bookmarklet make the comment title for 3rd party ci as gray.
javascript:(function(){list =
document.querySelectorAll('td.GJEA35ODGC'); for(i in
list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML
list[i].innerHTML.search('CI|Ryu|Testing|Mine')
0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
enjoy :)
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support
On Fri, Mar 7, 2014 at 12:30 AM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: 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.openstack.org/#/c/65113/ (which remind me that i need to review it :) Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-announce] python-heatclient 0.2.7 released
On Wed, Feb 19, 2014 at 1:50 AM, Steve Baker sba...@redhat.com 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 things more robust and secure(tm) Chmouel. [1] I am not sure why it's not listed in that link ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] config sample tools on os x
On Thu, Feb 20, 2014 at 12:17 AM, Sergey Lukjanov slukja...@mirantis.comwrote: 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.launchpad.net/heat/+bug/1261370, the easy way would be to use bash builtin getopt but that would mean we would have to drop long options. Is dropping long options an (pun not sure if it's intended) option? Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: 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 sdist. However, we could I think that may slighty complicate more devstack with this, since we rely heavily on config samples to setup the services. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Python 3 compatibility
On Mon, Feb 3, 2014 at 5:29 PM, Julien Danjou jul...@danjou.info 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. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Zane Bitter zbit...@redhat.com 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 add me to the review and I will do my best to help. Thanks for writing this up Zane, I have been often confused with the modeling system of Heat, it may be worthwhile to store this in documentation or a blog article. Cheers, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hacking repair scripts
On Tue, Jan 28, 2014 at 2:13 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: 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: emacs/vim) Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchicical Multitenancy Discussion
On Tue, Jan 28, 2014 at 7:35 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: 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 the projects, this concept is pretty useless. FYI: swift and keystoneauth allow to have cross project ACLs Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][oslo] Upgrade six to 1.5.2?
On Wed, Jan 22, 2014 at 11:17 AM, Julien Danjou jul...@danjou.info 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) six 1.4.1 is lack of urllib/urlparse support, so oslo-incubator/py3kcompat is needed, and it is used in some projects, if we upgrade six, should we remove py3k in the same time, or just leave those code there? Upgrade and remove our own code, that'd be better. I think us all +1 less code we maintain is a good thing :) Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones c...@tenshu.net 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/openstack/python-openstackclient ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 4:37 PM, Jesse Noller jesse.nol...@rackspace.comwrote: 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 FYI: python-requests is using urllib3 for its backend (which use httplib after that). Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 5:23 PM, Jay Pipes jaypi...@gmail.com 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 there is no way to disable compression using requests which is a requirement for performances with swift (and security). see: https://review.openstack.org/#/c/33473/ and: https://github.com/kennethreitz/requests/issues/1853 Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 8:40 PM, Donald Stufft don...@stufft.io wrote: On Jan 16, 2014, at 2:36 PM, Joe Gordon joe.gord...@gmail.com 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 This seems like the biggest win to me. +1 Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Organizing a Gate Blocking Bug Fix Day
On Thu, Jan 9, 2014 at 1:46 PM, Sean Dague s...@dague.net 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 EU time). Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
On Thu, Jan 9, 2014 at 7:53 PM, Nachi Ueno na...@ntti3.com 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 neutron l2-agent on the same host of nova-compute. What about using for that something like the discoverability middleware that was added in swift[1] and extend it to get it integrated oslo? Chmouel. [1] http://techs.enovance.com/6509/swift-discoverable-capabilities ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] libvirt unit test errors
On Tue, Jan 7, 2014 at 2:28 PM, Gary Kotton gkot...@vmware.com wrote: 2014-01-07 11:59:47.428http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_11_59_47_428| Requirement already satisfied (use --upgrade to upgrade): markupsafe in ./.tox/py27/lib/python2.7/site-packages (from Jinja2=2.3-sphinx=1.1.2,1.2) This is being worked on https://bugs.launchpad.net/nova/+bug/1266711 Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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) vijayakumar.kodam@nsn.com 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. Then ceilometer should automatically update the meters without restarting. Why it cannot be something configured by the admin with inotifywait(1) command? Or this can be an API call for enabling/disabling meters which could be more useful without having to change the config files. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 thankfully we have an easier way to do it. I hereby +1 this I think we should just remove all editors specifics in .gitignore and leave it to the user to set this up which would be useful for him as well on other projects (i.e: not openstack) that doesn't have such .gitignore . Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 virtualenv). I have to resort to nose to get the proper error : http://pastie.org/pastes/8558525/text?key=o4hljmbmsakrekbzqvrfug do you know how to get the same output with testr than the above paste? Thanks, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33
On 10 Dec 2013, at 09:20, Morgan Fainberg m...@metacloud.com wrote: I think the correct way to sync is to run the update.py script and submit a review (I don’t think it’s changed recently). Seems pretty straightforward then, thanks. let see how the review goes here then : https://review.openstack.org/#/c/61042/ Cheers, Chmouel. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Catalog type naming guidelines
On Tue, Dec 10, 2013 at 3:57 PM, Sergey Lukjanov slukja...@mirantis.comwrote: we have a concern about the correct catalog type naming for projects who'd like to have a name like data processing. just out of interests why is it a problem and need to be standardized, isn't that supposed to be a free form field? Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: [qa][tempest] Bug Triage Day - Thu 12th - Prep
would be nice to participate for the ppl interested with tempest Chmouel. -- Forwarded message -- From: Adalberto Medeiros adal...@linux.vnet.ibm.com Date: Tue, Dec 10, 2013 at 3:52 PM Subject: [openstack-dev] [qa][tempest] Bug Triage Day - Thu 12th - Prep To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Hi all! We have the Tempest Bug Triage Day this Thursday and there are a few points to start digging and investigating from now on. First let me share the guidelines link (Openstack Wiki for Bug Triage): https://wiki.openstack.org/wiki/BugTriage Starting from that, there are a few issues and observations to consider for discussion: 1) Confirmed and Triaged status. There seems to not have a consistency on those status, apparently being used as synonyms. Any thoughts on how or if we should differ them? 2) New Bugshttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=NEWassignee_option=none. We have 116 (and growing) new bugs to *prioritize, confirm and identify duplicates*. *This is where the team needs to put most of the effort.* There are also 5 New bugs assigned https://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=NEWorderby=assigneethat should be converted to Confirmed/ In Progress. 3) Confirmed and Triaged bugs: 13 assignedhttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDorderby=assigneeshould be changed to In Progress if it makes sense or removed assignees. The other 30 confirmed/triagedhttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDassignee_option=noneshould be prioritized. 4) 4 In Progress/ Fix Committedhttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=INPROGRESSfield.status%3Alist=FIXCOMMITTEDassignee_option=nonebugs should not remain unassigned. Either have someone assigned or move it back to Confirmed and ensure importance. 5) Old bugs: * 15 In Progresshttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status=In%20Progressorderby=date_last_updatedwith last update comments in October. Assignees should verify if the status still makes sense. If not, the bug may be moved back to Confirmed/Invalid and prioritized accordingly. * Confirmed/Triagedhttps://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDorderby=date_last_updated: review importances and assignees. Also look for duplicates. I think the focus on Thursday should be specially on item 2, but also looking at 3. I'll start looking at those points and all the help here is appreciated. The final goal is to have this process well established to avoid getting a huge list of new bugs without review. Please, all thoughts/opinions will be really appreciated. Best regards, -- Adalberto Medeiros Linux Technology Center Openstack and Cloud Development IBM Brazil Email: adal...@linux.vnet.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OK to Use Flufl.enum
On Tue, Dec 10, 2013 at 5:23 PM, Jay Pipes jaypi...@gmail.com wrote: The IntEnum is my new definition of the most worthless class ever invented in the Python ecosystem -- taking the place of zope.interface on my personal wall of worthlessness. this is the kind of things you can do with the new Enums : http://blog.dbrgn.ch/2013/5/10/python-enum-type/ I personally don't find them very useful either but they may have some use cases. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Core criteria, review stats vs reality
On Tue, Dec 10, 2013 at 11:26 AM, Thierry Carrez thie...@openstack.orgwrote: That's why I thought creating VIP parties for +2 reviewers (or giving them special badges or T-shirts) is spreading the wrong message, and encourage people to hang on to the extra rights associated with the duty. +1 million Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] python-swiftclient, verifying SSL certs by default
Hello, There has been a lengthy discussion going on for quite sometime on a review for swiftclient here : https://review.openstack.org/#/c/33473/ The review change the way works swiftclient to refuse to connect to insecure (i.e: self signed) SSL swift proxies unless you are specifying the --insecure flag to the CLI. This change the default behavior of the client but that's for the greater good of a better security. We are getting this merged now and want to make sure that people are aware of it first. We would probably bump the version of swiftclient to 2.0 since this is a big change. This would allow to close this CVE: https://bugs.launchpad.net/bugs/cve/2013-6396 and give ability to distributors for providing updates. I'll announce it on -users and -operators after this is merged. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Store quotas in Keystone
Hello, I was wondering what was the status of Keystone being the central place across all OpenStack projects for quotas. There is already an implementation from Dmitry here : https://review.openstack.org/#/c/40568/ but hasn't seen activities since october waiting for icehouse development to be started and a few bits to be cleaned and added (i.e: the sqlite migration). It would be great if we can get this rekicked to get that for icehouse-2. Thanks, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On Sun, Dec 1, 2013 at 11:10 PM, Alessandro Pilotti apilo...@cloudbasesolutions.com wrote: We’ll follow up with a blog post with some additional news related to this project quite soon. really cool, I'd love to use that for my apple laptop. It would be nice if it goes on stackforge which should be easier to contribute. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
