Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules

Hey Kevin, Thanks for the offer. We had discussed pulling in the module you wrote for OSAD originally. The main blocker was we had an internal requirement of being able to use Keystone v3 api. I have looked at the patch to make OSAD v3, but it appears you are importing v3 directly rather than lett

[openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

Hi all, I've been researching the Neutron project as a part of work on Openstack rolling upgrades, my primary assignments included testing if there is no VM access downtime when performing upgrade. Are you aware of any issues that are present in Liberty release of Neutron, that may cause the VM

Re: [openstack-dev] Thoughts on ReleaseNoteImpact git commit message tag

2015-07-08 18:45 GMT+02:00 Thierry Carrez : > Soren Hansen wrote: >> Putting release notes in the git repo so that they simply will get >> merged along with the corresponding code seems like a no-brainer. What >> am I missing? > For stable branches it prevents us from just backporting master change

[openstack-dev] [Fuel] Introducing bash unit testing

Hi all, as hopefully everyone knows, it's very challenging to prove that Bash encourages writing readable, maintainable code that actually works first time it is run. Sadly we have quite a long history of merging various shell scripts without any test coverage. Fortunately Peter Zhurba bore with

Re: [openstack-dev] [Magnum][Anchor][Barbican] Magnum as a CA

Hi, On Thu, Jul 9, 2015 at 11:13 AM, OTSUKA, Motohiro wrote: > I think it’s better to use Barbican, > It provides CA function and also secure key storage. > Agree. Barbican is suitable for us in both the cases, for generating certs and also its storage. But I am not sure whether Barbican can b

Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

The serie of patchsets is available here: https://review.openstack.org/#/q/status:open+branch:master+topic:db_sync,n,z Thanks in advance for your feedbacks, -- Yanis Guenane On 06/25/2015 10:02 AM, Yanis Guenane wrote: > > On 06/09/2015 04:07 PM, Mathieu Gagné wrote: >> On 2015-06-08 2:48 AM, Ya

Re: [openstack-dev] [Fuel] Introducing bash unit testing

What about bashate? It is already in use in several OpenStack projects? https://github.com/openstack-dev/bashate On Jul 9, 2015 11:15 AM, "Bartlomiej Piotrowski" wrote: > Hi all, > > as hopefully everyone knows, it's very challenging to prove that Bash > encourages > writing readable, maintainab

Re: [openstack-dev] [Fuel] Introducing bash unit testing

I am one hundred percent support this proposal. Just to clarify, did you consider shunit2 [1 ] as a unittest framework for Bash? It seems a little bit closer to shell scripting itself, so you don't need to learn another syntax

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

+1 and another one to Tatyana's suggestion. Bartłomiej On Wed, Jul 8, 2015 at 6:24 PM, Sergii Golovatiuk wrote: > +1 > > On Wed 8 Jul 2015 at 11:13 Tatyana Leontovich > wrote: > >> Hi, >> If we plan to make a changes here, lets choose one of ha env with ceph >> (or cinder, but ceph is preferab

Re: [openstack-dev] [Fuel] Introducing bash unit testing

On Thu, Jul 9, 2015 at 10:24 AM, Matthew Mosesohn wrote: > What about bashate? It is already in use in several OpenStack projects? > > https://github.com/openstack-dev/bashate > To be honest, I don't see any value of using bashate. It does some basic checks but none of them is insightful. Shellch

Re: [openstack-dev] [Fuel] Introducing bash unit testing

On Thu, Jul 9, 2015 at 10:27 AM, Oleg Gelbukh wrote: > I am one hundred percent support this proposal. > > Just to clarify, did you consider shunit2 > [1 ] > as a unittest framework for Bash? It seems a little bit closer to sh

[openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

Hi list, As the subject says, we are starting a new Neutron subproject that aims to service the Docker Container Network Model[1] by leveraging Neutron in a way similar to how Nova does. So far, while we set up a subproject, we have a repo[2] where you can see a bit more explanation about what t

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Matt, I don't think it's a bike-shedding. The problem is not the existing name being a bit obscure - until I hit some issues with Keystone native regions I didn't have any troubles with it. The problem is that we have the _same_ name for different things, and no additional comments will remedy the

[openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

> Hello everyone, > > I took some time this morning to write out a document[0] that outlines > one possible ways for us to manage our upstream modules in a more > consistent fashion. I know we've had a few emails bouncing around > lately around this topic of our use of upstream modules and how can

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Robert Collins wrote: >> I'm wondering if we should not refresh them less often. Some of those >> will trigger some discussion before approval > > ^ if they do, its bogus discussion. We never had discussion previously > when new deps flowed into gate jobs willy-nilly - except when it went > wrong.

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 07/08/2015 07:07 PM, Robert Collins wrote: > On 9 July 2015 at 09:08, Sean Dague wrote: > >> So I think the issue is that we used to have a manual process (reviewing >> g-r adds), and some automated stuff that happens after that. >> >> Now we seem to have a manual process, that triggers some a

Re: [openstack-dev] [manila] share dismantling policies

1) There is no cases that can come in my mind when some share backend can not be configured (separately from Manila) to destroy data for sure, like filling with zeros, etc... And it is OK to make share driver do it. 2) Agree that it is a problem. But Manila has no power on users to force them stop

[openstack-dev] [infra] Process to install a gem on jenkins slave

Hello, In PuppetOpenstack we would like to use modulesync[1] in order to synchronize common file accross modules via a post-merged hook(WIP)[2]. In order for this script to work modulesync needs to be installed on the nodes. Modulesync isn't packaged for any distro AFAIK so it would need to be in

Re: [openstack-dev] [tc] [all] thinking additional tags

On 07/08/2015 06:12 PM, Steve Baker wrote: > On 09/07/15 04:39, Zane Bitter wrote: >> On 08/07/15 09:03, Sean Dague wrote: >>> Personally, I'm running out of steam on tags for this cycle, but Zane >>> brought up a good point in the TC meeting yesterday, which was that "it >>> would be nice to have

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

+1 2015-07-09 11:30 GMT+03:00 Bartlomiej Piotrowski : > +1 and another one to Tatyana's suggestion. > > Bartłomiej > > On Wed, Jul 8, 2015 at 6:24 PM, Sergii Golovatiuk < > [email protected]> wrote: > >> +1 >> >> On Wed 8 Jul 2015 at 11:13 Tatyana Leontovich >> wrote: >> >>> Hi, >>> If we

Re: [openstack-dev] [tc] [all] thinking additional tags

On 07/08/2015 12:51 PM, Thierry Carrez wrote: > Sean Dague wrote: >> Personally, I'm running out of steam on tags for this cycle, but Zane >> brought up a good point in the TC meeting yesterday, which was that "it >> would be nice to have tags for criteria that we used to use for >> integration req

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

If docker cant be used in the name, Kuryr sounds good to me :) On Thu, Jul 9, 2015 at 11:55 AM, Antoni Segura Puimedon < [email protected]> wrote: > Hi list, > > As the subject says, we are starting a new Neutron subproject that > aims to service the Docker Container Network Model[1]

Re: [openstack-dev] [tc] [all] thinking additional tags

Sean Dague wrote: > On 07/08/2015 12:51 PM, Thierry Carrez wrote: >> Sean Dague wrote: >>> Personally, I'm running out of steam on tags for this cycle, but Zane >>> brought up a good point in the TC meeting yesterday, which was that "it >>> would be nice to have tags for criteria that we used to us

[openstack-dev] [heat] Why heat needs a keystone user per resource ?

Hi, Heat creates a keystone user for every resource which uses a CFN_SIGNAL. Heat also stores their AWS credentials in the heat.resource_data table. These credentials/users are restricted to operate only on limited (1?) resource, with very limited operations (3?). Normally these resource users ar

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 9 July 2015 at 21:13, Thierry Carrez wrote: > Robert Collins wrote: >>> I'm wondering if we should not refresh them less often. Some of those >>> will trigger some discussion before approval >> >> ^ if they do, its bogus discussion. We never had discussion previously >> when new deps flowed int

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 9 July 2015 at 21:50, Sean Dague wrote: > Maybe, I'm not convinced though. This should be just like config file > samples, yes you need to stay on top of them, especially as libraries > release, but it should be fine. Reviewers can also regen pretty easily > to get things to pass tests. I do m

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Robert Collins wrote: > On 9 July 2015 at 21:13, Thierry Carrez wrote: >>> [...] >>> So lets make this a single +A from any core. Its not code review so >>> much as 'it looks green and we're not in release-freeze right now'. >> >> OK, so we are not supposed to review the contents of the file (like

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 9 July 2015 at 11:43, Robert Collins wrote: > On 9 July 2015 at 21:13, Thierry Carrez wrote: >> https://review.openstack.org/#/c/199353/1/upper-constraints.txt > > So thats folk learning about what goes on. That may happen from time > to time, but since upper-constraints *isn't* a policy knob

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 9 July 2015 at 11:59, Dave Walker wrote: > On 9 July 2015 at 11:43, Robert Collins wrote: >> On 9 July 2015 at 21:13, Thierry Carrez wrote: > > > As you said later, if it is green - then the code base has presumably > proved it can work with that version, so sync' it across. Shortly aft

Re: [openstack-dev] [glance] Progress of the Python 3 port

Hi, gate-glance-python34 is now voting! Ian Cordasco and Erno Kuvaja approved my two last patches to port glance_store to Python 3: thanks. "tox -e py34" now pass successfully, cool! I proposed a "Make gate-glance_store-python34 voting, add gate" patch to avoid Python 3 regressions in glance_

Re: [openstack-dev] [heat] Why heat needs a keystone user per resource ?

On Thu, Jul 09, 2015 at 06:28:33AM -0400, Attila Fazekas wrote: > Hi, > > Heat creates a keystone user for every resource which uses a CFN_SIGNAL. > Heat also stores their AWS credentials in the heat.resource_data table. This is true, a possible improvement might be to not store those credentials

Re: [openstack-dev] Segmentation Fault in nova-compute service on ARM platform.

Hi Hans, I did traced the function responsible for segmentation fault itz in file ceval.c. find below if (*next_instr == SETUP_FINALLY) { /* Make the last opcode before a try: finally: block uninterruptible. */ goto fast_next_opcode;

Re: [openstack-dev] [Openstack] Rescinding the M name decision

Isn't Mita a trademark of Kyocera they use for their copier business? Folks should read up on Musashi Miyamoto https://en.m.wikipedia.org/wiki/Musashi_Miyamoto if you want a name that resonates with our Japanese colleagues. -- mark > On Jul 8, 2015, at 11:48 PM, Somanchi Trinath > wrote: >

Re: [openstack-dev] [devstack] openstack install error with stable/kilo

Hi, I just tried with devstack stable/kilo on Ubuntu 14.04 but did not see the issue you saw. Do you have anything special in your localrc file? You could run "pip show paste" to see if the expected package is properly installed on your devstack. And you could manually install paste if it's not

Re: [openstack-dev] [ceilometer] virtual mid-cycle tomorrow (9th) and Friday (10th)

On Wed, 8 Jul 2015, Chris Dent wrote: The ceilometer mid-cycle is virtual and starts tomorrow (Thursday 9th of July) at 0700 UTC. The topical agenda is here: https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle and the daily schedule is here: https://www.google

Re: [openstack-dev] [manila] share dismantling policies

Hi Valeriy, thanks for your comments. It is true that I took the opportunity to ask for opinions about what would be considered good practice. Yet my main point was -- and my fault if I missed to get it through -- to reach a definite statement about general *minimum security requirements* for dri

Re: [openstack-dev] [devstack] openstack install error with stable/kilo

I tried again with a fresh VM and I don"t see this error anymore. On Thu, Jul 9, 2015 at 2:48 PM, Xiangfei Zhu wrote: > Hi, > > I just tried with devstack stable/kilo on Ubuntu 14.04 but did not see > the issue you saw. Do you have anything special in your localrc file? > > You could run "pip

[openstack-dev] [stable] dashboard for stable integrated releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi stables, I've sent a gerrit dashboard template for stable-maint team: https://review.openstack.org/200069 Please review, use and provide feedback. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVnnWkAAoJEC5aWaUY1u57elAIAJx

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

On 7/9/15, 01:34, "Flavio Percoco" wrote: >On 08/07/15 22:52 +, Jeremy Stanley wrote: >>On 2015-07-09 10:37:17 +1200 (+1200), Robert Collins wrote: >>> So - I'm looking to: >>> >>> A) have a discussion and identify any issues with moving testr out of >>> the venvs. (Note: this doesn't mean

Re: [openstack-dev] [Openstack] Rescinding the M name decision

In the hope of forestalling an unnecessary sub-thread... Mita was #1 in the vote, so has presumably already been ruled out by OpenStack's legal review. On 09/07/15 13:14, Mark Carlson wrote: Isn't Mita a trademark of Kyocera they use for their copier business? Folks should read up on Musashi

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

Excerpts from Robert Collins's message of 2015-07-09 10:37:17 +1200: > I don't remember if this has previously been discussed, but as our > Python3 readiness increases folk are going to feel pain from testr due > to a silly Python 2/3 incompatibility around dbm files. > > https://bugs.launchpad.ne

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

Or a database per python major version (or at least gracefully handle the incompatibility). --Morgan Sent via mobile > On Jul 9, 2015, at 06:43, Doug Hellmann wrote: > > Excerpts from Robert Collins's message of 2015-07-09 10:37:17 +1200: >> I don't remember if this has previously been discu

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Excerpts from Robert Collins's message of 2015-07-09 11:17:41 +1200: > On 9 July 2015 at 11:02, Doug Hellmann wrote: > > Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200: > >> I'd like to make the job run automatically immediately that we cut a > >> release of anything. And I'd

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Excerpts from Robert Collins's message of 2015-07-09 11:07:44 +1200: > On 9 July 2015 at 09:08, Sean Dague wrote: > > > So I think the issue is that we used to have a manual process (reviewing > > g-r adds), and some automated stuff that happens after that. > > > > Now we seem to have a manual pr

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 07/09/2015 10:02 AM, Doug Hellmann wrote: > Excerpts from Robert Collins's message of 2015-07-09 11:17:41 +1200: >> On 9 July 2015 at 11:02, Doug Hellmann wrote: >>> Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200: I'd like to make the job run automatically immediately

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2015 09:01 AM, Artur Korzen wrote: > Hi all, > > I've been researching the Neutron project as a part of work on > Openstack rolling upgrades, my primary assignments included testing > if there is no VM access downtime when performing upgrad

Re: [openstack-dev] [Fuel] Introducing bash unit testing

On 2015-07-09 11:24:14 +0300 (+0300), Matthew Mosesohn wrote: > What about bashate? It is already in use in several OpenStack projects? [...] It's a style checker (its name is an allusion to the "pep8" tool for checking Python coding style conventions). And shellcheck (mentioned later in this thre

Re: [openstack-dev] [release-tools] Launchpad permissions

Excerpts from Robert Collins's message of 2015-07-08 13:31:52 +1200: > I think we need a checklist of what to do when adding someeone to the > release team - either library or servers. > > I just released python-cinderclient, and found out the hard way that > my account doesn't have the right acce

[openstack-dev] [Fuel][Plugins] Scope of 7.0 Fuel Plugin Framework features

Hi to all, Please, be informed that the following features will enter Fuel Plugin Framework in 7.0 Fuel release: - define a new role through Fuel Plugins [1] - reserve VIP addresses via Fuel Plugin's metadata [2] If you plan to develop a plugin for Fuel, take these changes into consideration. T

Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules

Sam thanks for the review / heads up, that's awesome! -- Kevin Carter From: Sam Yaple Sent: Thursday, July 9, 2015 1:57 AM To: Steven Dake (stdake) Cc: OpenStack Development Mailing List (not for usage questions); Greg DeKoenigsberg Subject: Re: [openstack-dev

Re: [openstack-dev] [glance] Progress of the Python 3 port

On 7/9/15, 06:25, "Victor Stinner" wrote: >Hi, > >gate-glance-python34 is now voting! > >Ian Cordasco and Erno Kuvaja approved my two last patches to port >glance_store to Python 3: thanks. "tox -e py34" now pass successfully, >cool! I proposed a "Make gate-glance_store-python34 voting, add gat

Re: [openstack-dev] [Openstack] Rescinding the M name decision

On 07/09/2015 09:19 AM, Neil Jerram wrote: > In the hope of forestalling an unnecessary sub-thread... > > Mita was #1 in the vote, so has presumably already been ruled out by > OpenStack's legal review. That is correct. -- Russell Bryant

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

On Thu, Jul 9, 2015 at 3:55 AM, Antoni Segura Puimedon < [email protected]> wrote: > Hi list, > > As the subject says, we are starting a new Neutron subproject that > aims to service the Docker Container Network Model[1] by leveraging > Neutron in a way similar to how Nova does. > > T

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2015 10:55 AM, Antoni Segura Puimedon wrote: > Names: Kuryr - Czech name for Courier since it is delivering > networking to containers. v: apuimedo+1 :) If you stick to it, make sure you provide info on how it's pronounced . Ihar -BEGI

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

On 07/09/2015 04:55 AM, Antoni Segura Puimedon wrote: > Hi list, > > As the subject says, we are starting a new Neutron subproject that > aims to service the Docker Container Network Model[1] by leveraging > Neutron in a way similar to how Nova does. > > So far, while we set up a subproject, we

[openstack-dev] [sdks] Nominating Ghe Rivero for os-client-config-core

Hey all! Ghe has been doing a great job both in writing patches and reviewing for os-client-config and I'd like to add him to the core team. He's got a good handle on what we're doing, and more importantly what we're not doing. Monty __

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

Yes. Though the code that I have has been mostly written with OVN and Open vSwitch in mind, it uses Neutron APIs and integrates well with OpenStack. The docker plugin code that I have currently uses "no-auth" mode of Neutron, but there is no reason for it to not work with "auth" (as shown in https:

[openstack-dev] [fuel] Meeting July - 9

Please note the IRC meeting is scheduled for 16:00 UTC in #openstack-meeting-alt today. Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Cep

[openstack-dev] [all][heat][oslo] Public show and validation clients methods

Hi community. I want to raise couple questions about openstack clients. In Heat we use other python-*clients for manipulating service's resources, but some stuff placed in shell.py modules and we are forced to duplicate some existing code. There are couple examples which I met last time: - getti

[openstack-dev] UNSUBSCRIBE

Dell - Internal Use - Confidential UNSUBSCRIBE __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailma

[openstack-dev] [nova] Nova API meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Friday UTC1200. In other timezones the meeting is at: EST 08:00 (Fri) Japan 21:00 (Fri) China 20:00 (Fri) United Kingdom 13:00 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/wi

Re: [openstack-dev] [infra] Process to install a gem on jenkins slave

On 2015-07-09 11:52:14 +0200 (+0200), Yanis Guenane wrote: > In PuppetOpenstack we would like to use modulesync[1] in order to > synchronize common file accross modules via a post-merged hook(WIP)[2]. > > In order for this script to work modulesync needs to be installed on the > nodes. Modulesync

[openstack-dev] [Rally][Agenda]

Hi, its a friendly reminder that if you what to discuss some topics at Rally meetings, please add you topic to our Meeting agenda https://wiki.openstack.org/wiki/Meetings/Rally#Agenda. Don't forget to specify by whom led this topic. Add some information about topic(links, etc.) Thank you for your a

Re: [openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard

What bugs exist on the Launch Instance based off Angular? I'd like to help fix some. -Rajat On Tue, Jul 7, 2015 at 8:29 AM, Rob Cresswell (rcresswe) wrote: > The current issue is that we can’t force Angular when we have so little > code ourselves. The framework is fairly solid now, but there i

[openstack-dev] [mistral] Spec for : expiration-policies-for-executions

Hi, we have just create some spec in etherpad for "expiration-policies-for-executions". This have been discussed already but in this we getting more into the functionality details. You are more than welcome to add your comments in this page : https://etherpad.openstack.org/p/expiration-policie

Re: [openstack-dev] openstack command line and --help for subcommands

Excellent. Can the tickets be assigned to me and re-opened? From: Steve Martinelli [mailto:[email protected]] Sent: Wednesday, July 08, 2015 8:28 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] openstack command line and --help for subcommands S

Re: [openstack-dev] [sdks] Nominating Ghe Rivero for os-client-config-core

> On Jul 9, 2015, at 10:59 AM, Monty Taylor wrote: > > Hey all! > > Ghe has been doing a great job both in writing patches and reviewing for > os-client-config and I'd like to add him to the core team. He's got a > good handle on what we're doing, and more importantly what we're not doing. +1

Re: [openstack-dev] [all][heat][oslo] Public show and validation clients methods

I would think the python-openstackclient would smooth out a lot of the rough edges particularly the find by name or id situation. It already does that for many services neutron being the biggest gap. The python-openstacksdk will eventually (soon) be able to address a lot of those issues. On Thu

Re: [openstack-dev] [fuel] Meeting July - 9

Minutes are available http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-09-16.00.html On Thu, Jul 9, 2015 at 8:16 AM Andrew Woodward wrote: > Please note the IRC meeting is scheduled for 16:00 UTC in > #openstack-meeting-alt today. > > Please review meeting agenda and update if the

Re: [openstack-dev] [sdks] Nominating Ghe Rivero for os-client-config-core

> > > On Jul 9, 2015, at 10:59 AM, Monty Taylor wrote: > > > > Ghe has been doing a great job both in writing patches and reviewing for > > os-client-config and I'd like to add him to the core team. He's got a > > good handle on what we're doing, and more importantly what we're not > doing. > +1

Re: [openstack-dev] openstack command line and --help for subcommands

Hey Sean, 1444983 has been reopened and assigned to you. Thanks! https://bugs.launchpad.net/python-openstackclient/+bug/1444983 I am leaving 1251290 as invalid, since I feel it's a dupe of 1444983 Thanks, Steve Martinelli OpenStack Keystone Core From: "Perry, Sean" To: "OpenStack Deve

[openstack-dev] [all] Setting epoch in setup.cfg??

Hi all, I was thinking about those who are packaging with venvs (and using the version of a project in the venv file name); like what anvil[1] is now capable of (and does this in the gate now[2]) or packaging via rpms (which anvil also does) and they are going to be affected by the version sh

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Had the same issue when I worked on the context selection menu for switching domain and project. I think it make sense to rename it to AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its going to affect some folks (maybe even break) until they also update their setting, something that

Re: [openstack-dev] [all][heat][oslo] Public show and validation clients methods

Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300: > Hi community. > > I want to raise couple questions about openstack clients. > In Heat we use other python-*clients for manipulating service's resources, > but some stuff placed in shell.py modules and we are forced to duplicate

Re: [openstack-dev] [Fuel] Introducing bash unit testing

And I realized all of a sudden that even more interesting than unittest framework itself would be some analog of Python mock for shell scripts. Though I doubt that anyone ever really gone that far. -- Best regards, Oleg Gelbukh On Thu, Jul 9, 2015 at 5:12 PM, Jeremy Stanley wrote: > On 2015-07-

Re: [openstack-dev] openstack command line and --help for subcommands

Thanks Steve. From: Steve Martinelli [mailto:[email protected]] Sent: Thursday, July 09, 2015 11:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] openstack command line and --help for subcommands Hey Sean, 1444983 has been reopened and assign

Re: [openstack-dev] [glance] The sorry state of our spec process

Ok, I guess I'll bite my own thread and provide some feedback: We hold a glance-drivers meeting every week on Tuesdays at 14 UTC. In this week's meetingi[0], we discussed a bit the problems we have in the current workflow. Here's some feedback from that meeting. (Please, other folks, do chime in

Re: [openstack-dev] Cinder as generic volume manager

I missed this whole thread due to my mail filtering. Sorry about that. Anyway, Ivan and I have an open Blueprint here: https://blueprints.launchpad.net/cinder/+spec/use-cinder-without-nova That starts the discussion of adding the end to end ability of attaching a Cinder volume to a host using

Re: [openstack-dev] [Openstack] Rescinding the M name decision

> On Jul 9, 2015, at 9:35 AM, Russell Bryant wrote: > > On 07/09/2015 09:19 AM, Neil Jerram wrote: >> In the hope of forestalling an unnecessary sub-thread... >> >> Mita was #1 in the vote, so has presumably already been ruled out by >> OpenStack's legal review. > > That is correct. Hi everyo

[openstack-dev] [glance] A better way to reach out the entire community

Greetings, Before I even get started with this email, I'd like to make it clear that I'm sending it out assuming the good faith of everyone and the willingness of the Glance community to work together on improving our workflow. We all do what we do on the best interests of the project. My holida

Re: [openstack-dev] [tc] [all] thinking additional tags

On 08/07/15 18:12, Steve Baker wrote: On 09/07/15 04:39, Zane Bitter wrote: On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria

[openstack-dev] [glance] Additions/Removals to/from glance-drivers

Greetings, I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart has a huge amount of knowledge about Glance's history, he knows the Glance codebase well and he also has experience in deploying and maintaning Glance production environments. Stuart has shown his interest in joini

Re: [openstack-dev] [Cinder] python-cinderclient functional tests

On 21:48 Jul 06, Ivan Kolodyazhny wrote: > Aslo, what do you think about moving cinderclient functional tests from > experimental to non-voting queue to make it more public and run it with > every patch to python-cinderclient? I'm fine with this as long as the job has been stable since it was i

Re: [openstack-dev] [Openstack] Rescinding the M name decision

Feel free to give input on the Mitaka proposal. Tim > -Original Message- > From: Jonathan Bryce [mailto:[email protected]] > Sent: 09 July 2015 20:52 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decisio

Re: [openstack-dev] Cinder as generic volume manager

Hi all, Just FYI, here is a sample script I'm using for testing os-brick which attaches/detaches the cinder volume to the host using cinderclient and os-brick: https://gist.github.com/tsekiyama/ee56cc0a953368a179f9 "python attach.py " will attach the volume to the executed host and shows a volum

Re: [openstack-dev] [nova][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends

On 16:47 Jun 30, Mike Perez wrote: > On 12:24 Jun 26, Matt Riedemann wrote: > > > So the question is, is everyone OK with this and ready to make that change? > > Thanks for all your work on this Matt. > > I'm fine with this. I say bite the bullet and we'll see the CI's surface that > aren't ski

Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno

On 08:49 Jun 23, Mike Perez wrote: > There was a bug raised [1] from some large deployments that the Cinder > client 1.2.0 and beyond is not working because of version discovery. > Unfortunately it's not taking into account of deployments that have a > proxy. > > Cinder client asks Keystone to fin

Re: [openstack-dev] [cinder] Huawei CI's problem have been solved, and is reporting stably now.

On 02:08 Jul 01, liuxinguo wrote: > Hi Mike, > > We have solved the problem of Huawei CI, and it is running and reporting > stably now. The logs is also ok to access. > > We will be very appreciate if you can have a consider of remove the -2 review > to Huawei driver, thanks! ☺ > The following

[openstack-dev] [javascript] [qa] [eslint-config-openstack] Nominating Cindy Lu for eslint-config-openstack-core

Hey everyone! We've been hard at work getting some solid, shared code style rules in place for our javascript code, and nobody's been more diligent about this than Cindy Lu. Since we've managed to encapsulate our eslint configuration into a separate project (much like hacking), I'd like to nominat

Re: [openstack-dev] [cinder] Need help from folks working on Dell, Storpool and Infortrend drivers

On 10:58 Jun 29, Sheng Bo Hou wrote: > Hi everyone, > > For folks who are working on Dell, Storpool and Infortrend drivers: > I have got a new patch for https://review.openstack.org/#/c/180873. There > is a change about how to implement the method update_migrated_volume for > each driver. > The

[openstack-dev] [glance] Additions and removals for the glance-drivers team

Greetings, I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart has a huge amount of knowledge about Glance's history, he knows the Glance codebase well and he also has experience in deploying and maintaning Glance production environments. Stuart has shown his interest in joini

[openstack-dev] [tc] Adding rpm-packaging to the openstack git namespace

Hello OpenStackers, hello TC, Haikel and I have just submitted an update to the change to the governance repo to add RPM packaging to the OpenStack projects: https://review.openstack.org/#/c/191587 As a start there we'd like to do a dual PTL from Red Hat (Haikel) and SUSE (myself) and we'd like

Re: [openstack-dev] [glance] Additions/Removals to/from glance-drivers

Apparently I sent this email twice... disregard this one On 09/07/15 21:13 +0200, Flavio Percoco wrote: Greetings, I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart has a huge amount of knowledge about Glance's history, he knows the Glance codebase well and he also has expe

Re: [openstack-dev] [javascript] [qa] [eslint-config-openstack] Nominating Cindy Lu for eslint-config-openstack-core

On Thu, Jul 9, 2015 at 1:33 PM, Michael Krotscheck wrote: > Hey everyone! > > We've been hard at work getting some solid, shared code style rules in > place for our javascript code, and nobody's been more diligent about this > than Cindy Lu. Since we've managed to encapsulate our eslint configura

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

Thanks Ihar comments! > > Is Neutron ready to be upgradable with minimal downtime of services > > and no VM access downtime? > > As the ovs bug you refer to above, no, at least not in reference > implementation. That's for data plane. My understanding is that after the ovs neutron agent will be

Re: [openstack-dev] [manila] share dismantling policies

On 07/08/2015 03:38 AM, Csaba Henk wrote: Hi, I'm tossing in the term "dismantling" to indicate the act of making a share less available (deprovision (deny access to) / unmanage / delete it). I find it ambiguous what is to be done with the share's data('s accessibility) upon dismantling. Wrt. t

[openstack-dev] [stable][kilo] Call for testing: 2015.1.1 candidate tarballs

Hi all, We are scheduled to publish 2015.1.1 Kilo point releases, on Thursday July 16th for Ceilometer, Cinder, Glance, Heat, Horizon, Ironic, Keystone, Neutron, Nova, Sahara and Trove. We'd appreciate anyone who could test the candidate 2015.1.1 tarballs, which include all changes aside from any

[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 07/09/2015

Hi Everyone, Thanks for joining the service chaining project meeting on 7/9/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ OpenStack Development Ma

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

On 07/09/2015 10:11 AM, Ihar Hrachyshka wrote: > On 07/09/2015 09:01 AM, Artur Korzen wrote: >> Hi all, > >> I've been researching the Neutron project as a part of work on >> Openstack rolling upgrades, my primary assignments included >> testing if there is no VM access downtime when performing >

[openstack-dev] [Fuel] wrong network for keystone endpoint in 6.1 ?

Hi, I'm running Fuel 6.1 and i've seen an interesting behavior which i think match bug [1] Basically the adminUrl & publicUrl part of keystone endpoint are different And the result of that is that you can't run keystone cli - i.e create/list tenants etc keystone --debug tenant-list /usr/local/l

  1   2   >