Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses

Am 08.07.2015 um 01:37 schrieb Mike Perez : > On 18:38 Jun 22, Marc Koderer wrote: >> >> Am 20.06.2015 um 01:59 schrieb John Griffith : >>> * The BaseVD represents the functionality we require from all drivers. >>> ​Yep >>> ​ >>> * The additional ABC classes represent features that are not requ

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

> On 08 Jul 2015, at 03:54, Zane Bitter wrote: > > On 07/07/15 06:13, Renat Akhmerov wrote: >> Just to clarify: what we’re looking for is how to implement “Work queue” >> pattern described at [1] with oslo messaging. As Nikolay said, it >> requires that a message to be acknowledged after it has

Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support

Le 2015-07-07 17:00, Mike Dorman a écrit : Ok, I see that now, too. I’m confused why the default is still 60 in olso.messaging 1.9.0 and 1.10.0 though? I confess I don’t completely understand the versioning here. This default have been changed to workaround the requirement issue, released

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

I have the same concern as a Chinese, Emperor Meiji will be linked to a war happened in 1895, also invasion of Taiwan. That is so bad historical memory for Chinese. Refer to : https://en.wikipedia.org/wiki/First_Sino-Japanese_War I recommend selecting another candidate. >It is totally understa

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

I'd like to propose we just use numbers for versioning our software. Both random words and the year.cadence scheme are irritating in their own special way. Why not make it Openstack 13.0 and let the downstream distributions play in the minefield that is naming software projects. - Michael On We

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Dear all, #4 was Mitaka (三鷹, meaning "three hawks"), I believe? Mitaka is a very beautiful city, if I may say so (I lived there, so I'm a bit biased :)), with Inokashira Park, a zoo, and many walking trails. Plus, the Ghibli Museum is there, which celebrates a very famous and well-loved anim

Re: [openstack-dev] [barbican] regarding certificate generation

Hi, I also test certificate generation on devstack. I added below configuration to barbican.conf. enabled_certificate_plugins = snakeoil_ca [snakeoil_ca_plugin] ca_cert_path = /path/to/ca_cert ca_cert_key_path = /path/to/ca_key and request ca list using curl curl -H 'con

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

It is totally understandable that the combination of "Japan" and "Meiji" recalls harsh history to some people, especially in East Asia. As a Japanese, I'm sorry for that. I think the release naming process should not cause such friction. Could we just select some other neutral candidate name inste

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi wrote: > Hi tempest team, > > We are working for refactoring service clients in tempest for > preparing to migrate them to tempest-lib, and I found an inconsistency > between them. > So I'd like to ask opinions for considering which is the best as

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Dear OpenStack Community, As Clint mentioned, there is some historical background regarding the name of "Meiji". I have been aware of the potential problem with "Meiji", however, I have not raise my voice here since it was not the top of the list. However, with current situation, IMHO, it is bett

Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?

On Fri, Jul 3, 2015 at 6:37 AM, Sylvain Bauza wrote: > > > Le 03/07/2015 15:25, Jay Pipes a écrit : > >> On 07/03/2015 06:32 AM, Sylvain Bauza wrote: >> >>> Le 02/07/2015 21:40, Jay Pipes a écrit : >>> On 07/01/2015 12:23 AM, ChangBo Guo wrote: > thanks Dan and Jay, we don't need a

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Hello Monty, Has the third candidate for our next release name 'Meiji' been determined and finalized? I know we are following open and relevant procedures (e.g., public polls) to determine our next release name, but I am asking it because I think 'Meiji' as our next release name would become

Re: [openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium

it seems two kinds of sub projects. one is vendor plugins, for which option #1 seems appropriate. another is things like l2gw and octavia, for which option #2 might make more sense. On Wed, Jul 8, 2015 at 12:23 AM, Kyle Mestery wrote: > After some consultation with Doug and Thierry, we've boiled

[openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

Hi tempest team, We are working for refactoring service clients in tempest for preparing to migrate them to tempest-lib, and I found an inconsistency between them. So I'd like to ask opinions for considering which is the best as library methods. On some methods, a caller can specify whole body fo

Re: [openstack-dev] [Neutron] Linux Bridge CI status report

On 07/07/2015 10:13 PM, Doug Wiegley wrote: > Great work. > > Doug Piling in on Doug's post, great work here Sean. Anita. > > >> On Jul 7, 2015, at 8:01 PM, Sean M. Collins wrote: >> >> Hi, >> >> At the risk of jinxing it, I'd like to report that with the merge of a >> couple patches to fix

Re: [openstack-dev] Should project name be uppercase or lowercase?

> > Forwarded Message > Subject:[openstack-dev] Should project name be uppercase or > lowercase? > Date: Tue, 7 Jul 2015 18:21:57 +0900 > From: Yuiko Takada > Reply-To: OpenStack Development Mailing List (not for usage > questions) > > To: OpenStack Develop

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

On 7/7/15, 2:05 PM, "Robert Collins" wrote: >On 4 July 2015 at 06:53, Steven Dake (stdake) wrote: >> Kolla Devs as well as the Technical Committee, >> >> I wanted to get the TC¹s thoughts on this plan of action as we intend to >> apply for big tent once our Ansible code has completed implement

Re: [openstack-dev] [Neutron] Linux Bridge CI status report

Great work. Doug > On Jul 7, 2015, at 8:01 PM, Sean M. Collins wrote: > > Hi, > > At the risk of jinxing it, I'd like to report that with the merge of a > couple patches to fix race conditions[1][2] and DevStack[3] - we're looking > at promising results for experimental runs for the Linux Br

[openstack-dev] [Neutron] Linux Bridge CI status report

Hi, At the risk of jinxing it, I'd like to report that with the merge of a couple patches to fix race conditions[1][2] and DevStack[3] - we're looking at promising results for experimental runs for the Linux Bridge CI on changes that are supposed to pass[4], as well as being useful for patches und

Re: [openstack-dev] Can't add a table to nova DB

Is this new table as part of a contribution to upstream nova, or for a private table? If its for a private table, then I'm not really sure that's a great idea -- for example what happens when we consume the migration number you use? If this code isn't private, perhaps it would be easiest to share

Re: [openstack-dev] [requirements] separating the code and data in openstack/requirements

On 2015-07-08 11:36:46 +1200 (+1200), Robert Collins wrote: > I wanted to see what folk thought about moving the requirements > management code (update.py etc etc) to a branchless model. [...] Seems like it's overdue, as a distinct python project has fully congealed within it now and the logic it

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

We've finally gotten all the kinks worked out and now upper-constraints proposals should be coming in daily. *** These are timely and important: without them, no new releases of *anything* are consumed. *** https://review.openstack.org/#/c/199353/ is an example. They are all in the topic https:/

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

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 access to cut releases. We might want to go further and have a lint mechanism to c

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

3 Months should be a good period. Sometimes, people have one month vacation thus it might be a problem in such cases. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 7, 2015 at 3:34 PM, Mike Scherbakov wrote: > Hi, > we have too many patches which hang for over a mon

Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses

On 18:38 Jun 22, Marc Koderer wrote: > > Am 20.06.2015 um 01:59 schrieb John Griffith : > > * The BaseVD represents the functionality we require from all drivers. > > ​Yep > > ​ > > * The additional ABC classes represent features that are not required yet. > > * These are represented by classes

[openstack-dev] [requirements] separating the code and data in openstack/requirements

I wanted to see what folk thought about moving the requirements management code (update.py etc etc) to a branchless model. e.g.: openstack/requirements - global-requirements.txt - upper-constraints.txt - README.rst - nothing else. Not even a setup.py. openstack-dev/requirements-tools - u

[openstack-dev] [third-party][infra] Reminder: Common OpenStack CI Virtual Sprint Wednesday July 8 1600 UTC (was [infra][third-party] Common-CI Virtual Sprint)

All, This is a reminder of the OpenStack-Infra Virtual Sprint[1] is scheduled for (tomorrow) Wednesday July 8 1600 UTC, and will run for 48hours. GOAL: By the end of the sprint, we should be able to setup a 3rd party CI system using the same puppet components that the OpenStack Infrastructure

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

On 07/07/15 06:13, Renat Akhmerov wrote: Just to clarify: what we’re looking for is how to implement “Work queue” pattern described at [1] with oslo messaging. As Nikolay said, it requires that a message to be acknowledged after it has been processed. Yeah, so as you've discovered, oslo.messagi

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

How often does this happen? Is it on every call? If not, is it possible the forking logic in require_state is messing up the DB handle when it's invoked? One way to make sure there aren't open transactions for testing is to just remove the "subtransactions=True" statement from update_port in the M

[openstack-dev] [all] Gerrit downtime on Friday 2015-07-10 at 22:00 UTC

Hi everyone, This Friday, July 10th, at 22:00 UTC Gerrit will be unavailable for about 30 minutes while we rename some projects. Existing reviews, project watches, etc, should all be carried over. Currently, we plan on renaming the following projects: stackforge/puppet-murano -> openstack/puppet

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

On 8 July 2015 at 08:53, Monty Taylor wrote: > On 07/07/2015 03:42 PM, Monty Taylor wrote: >> On 07/07/2015 03:00 PM, Doug Hellmann wrote: >>> Excerpts from Steve Martinelli's message of 2015-07-07 14:51:33 -0400: Direct dependency for functional testing: https://github.com/openstac

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

Excerpts from Robert Collins's message of 2015-07-07 14:05:23 -0700: > On 4 July 2015 at 06:53, Steven Dake (stdake) wrote: > > Kolla Devs as well as the Technical Committee, > > > > I wanted to get the TC’s thoughts on this plan of action as we intend to > > apply for big tent once our Ansible co

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

On 4 July 2015 at 06:53, Steven Dake (stdake) wrote: > Kolla Devs as well as the Technical Committee, > > I wanted to get the TC’s thoughts on this plan of action as we intend to > apply for big tent once our Ansible code has completed implementation. If > the approach outlined in this email seem

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

On 07/07/2015 03:42 PM, Monty Taylor wrote: > On 07/07/2015 03:00 PM, Doug Hellmann wrote: >> Excerpts from Steve Martinelli's message of 2015-07-07 14:51:33 -0400: >>> >>> Direct dependency for functional testing: >>> https://github.com/openstack/oslotest/blob/6bd1f64542d5826cef288b43210650b50ba02

Re: [openstack-dev] [puppet] Re: duplicate keystone endpoints

FYI I have created https://bugs.launchpad.net/puppet-openstacklib/+bug/1472396 for tracking this. I may have some time to work on this after our Kilo upgrade is done, but I can’t make any promises right now. From: Matt Fischer Reply-To: "puppet-openst...@puppetlabs.com

Re: [openstack-dev] [Fuel] Being spammed by bugs when assigned to whole fuel team

Hi, Mike, let me post a quote from #launchpad IRC chat: bookwar: hi all, is there any permission setting which forbids subscribing someone to the bug? As i see it, one can easily spam a group by subscribing it to a certain bug. How we can prevent this? mgz: ban the person doing the spamming

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

Well, I can run the upgrade command, but it doesn't seem to be processing my new migration file. I have tried using upgrade with 'head', and with the HEAD file set to the previous version and to the new version. In both cases, I get these info messages twice: "Context impl MySWLImpl." and "Will ass

[openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Hi, we have too many patches which hang for over a month without attention. Almost all are those which should be abandoned due to changes happened in master, and need complete rework. Or, those were just proposals to make something, which didn't fly. Unfortunately there are those which were good id

[openstack-dev] [Fuel] Being spammed by bugs when assigned to whole fuel team

Hi folks, DevOps guys - when someone assigns bug to "Fuel for OpenStack", message is being sent to 120 people. Is there a way to restrict such assignment in Launchpad? I want to only allow fuel-python, and other subteams available. Or do something with LP groups. The problem is that I'm getting t

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

I found the issue. The upgrade is looking for config to have [database] section and connection definition. If I use /etc/neutron/neutron.conf, then the neutron-db-manage runs. On Tue, Jul 7, 2015 at 3:38 PM Paul Michali wrote: > I have that change in the neutron repo that is being used with by

Re: [openstack-dev] [Fuel] python-fuelclient-6.1.2

Hi, Roman, could you please provide more info about versioning scheme of python-fuelclient project. It looks quite strange to me to see "Bump version to 7.0" patch in 6.1.2 changelog. In fuel-* repositories we used "x.y.z" as a tag on "stable/x.y" branch, but now we have stable/6.1.2 branch as a

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

I have that change in the neutron repo that is being used with by this neutron-vpnaas repo. On Tue, Jul 7, 2015 at 3:12 PM Mike Bayer wrote: > > > On 7/7/15 1:28 PM, Paul Michali wrote: > > HEAD, head, 24f28869838b (my new file) all say the same thing. :( > > > On Tue, Jul 7, 2015 at 12:34 PM S

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

On 07/07/2015 03:00 PM, Doug Hellmann wrote: > Excerpts from Steve Martinelli's message of 2015-07-07 14:51:33 -0400: >> >> Direct dependency for functional testing: >> https://github.com/openstack/oslotest/blob/6bd1f64542d5826cef288b43210650b50ba02ca3/oslotest/functional.py#L16 > > It looks like

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

Gordon Sim wrote: On 07/07/2015 05:48 PM, Clint Byrum wrote: all of the call sites I checked _do not appear to resend_, they simply explode on timeout waiting for reply. This is how calling code should work and I'm ok with code in nova, cinder, et. al. being written this way, because I'd expect

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

Gordon Sim wrote: On 07/07/2015 05:48 PM, Clint Byrum wrote: all of the call sites I checked _do not appear to resend_, they simply explode on timeout waiting for reply. This is how calling code should work and I'm ok with code in nova, cinder, et. al. being written this way, because I'd expect

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

+1 on all of Jay's conclusions. :) I¹m pretty new to OpenStack, but not at all to API, REST API, and web development in general, and I concur : ŒNova¹, ŒSwift¹, ŒKeystone¹ and so on makes it very hard to learn how things work in OpenStack and what each of those parts are responsible with. I¹ll be

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

On 7/7/15 1:28 PM, Paul Michali wrote: HEAD, head, 24f28869838b (my new file) all say the same thing. :( On Tue, Jul 7, 2015 at 12:34 PM Salvatore Orlando > wrote: possibly I was wrong in mixing up git & alembic. It should be "upgrade head" - lowercase.

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

On 07/07/2015 05:48 PM, Clint Byrum wrote: all of the call sites I checked _do not appear to resend_, they simply explode on timeout waiting for reply. This is how calling code should work and I'm ok with code in nova, cinder, et. al. being written this way, because I'd expect my messaging layer

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

Excerpts from Steve Martinelli's message of 2015-07-07 14:51:33 -0400: > > Direct dependency for functional testing: > https://github.com/openstack/oslotest/blob/6bd1f64542d5826cef288b43210650b50ba02ca3/oslotest/functional.py#L16 It looks like that's something the os-client-config library should

Re: [openstack-dev] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?

Excerpts from Ben Nemec's message of 2015-07-07 11:41:35 -0500: > On 07/04/2015 12:12 AM, Akihiro Motoki wrote: > > Hi Oslo and Neutron folks, > > > > Why is policy_dirs option deprecated in oslo.policy? > > In Neutron we have multiple repositories which consist of Neutron services > > and we woul

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

On 07/07/2015 01:31 PM, Doug Hellmann wrote: > Excerpts from Thomas Goirand's message of 2015-07-07 19:26:18 +0200: >> Hi, >> >> It seems that the above packages are build-depending on each other. We >> need this kind of thing to be broken. Can something be done? > > From looking at the requiremen

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

Direct dependency for functional testing: https://github.com/openstack/oslotest/blob/6bd1f64542d5826cef288b43210650b50ba02ca3/oslotest/functional.py#L16 Thanks, Steve Martinelli OpenStack Keystone Core From: Doug Hellmann To: openstack-dev Date: 2015/07/07 02:32 PM Subject:R

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

On Tue, Jul 07, 2015 at 09:35:13AM -0700, Dan Smith wrote: > > The thing is, UpgradeImpact isn't always appropriate for the change, > > but DocImpact is used too broadly and as far as I can tell, it's not > > really for updating release notes [2]. It's for updating stuff > > found in docs.openstac

Re: [openstack-dev] [oslo] Document API changes using Sphinx markups

Excerpts from Clint Byrum's message of 2015-07-07 09:13:39 -0700: > Excerpts from Victor Stinner's message of 2015-07-07 08:22:26 -0700: > > Hi, > > > > Oslo libraries become more and more stable, cool :-) Sometimes, we have > > to modify APIs, to fix bugs, to deprecate functions, to add new func

Re: [openstack-dev] [oslo] Document API changes using Sphinx markups

Another idea that I was going to do, but backed down from it, Was the following: https://review.openstack.org/#/c/155988/ Basically when a function would be marked with a debtcollector decorator/deprecation stuff it would also mutate the docstring and add on the rst section u just stated belo

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

Excerpts from Thomas Goirand's message of 2015-07-07 19:26:18 +0200: > Hi, > > It seems that the above packages are build-depending on each other. We > need this kind of thing to be broken. Can something be done? >From looking at the requirements files, it's not obvious why oslotest would have an

Re: [openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

On 07/07/2015 12:26 PM, Thomas Goirand wrote: > Hi, > > It seems that the above packages are build-depending on each other. We > need this kind of thing to be broken. Can something be done? > > Cheers, > > Thomas Goirand (zigo) > > ___

Re: [openstack-dev] [neutron] Breakage by commit 18bc67d56faef30a0f73429a5ee580e052858cb5

Filed [1], I think this affected more than just vpn. Fix coming shortly. Sorry, I thought I had taken the necessary measures :) [1] https://bugs.launchpad.net/neutron/+bug/1472361 On 7 July 2015 at 09:11, Armando M. wrote: > Hi Paul, > > Let me look into it. > > Thanks, > Armando > > On 7 July

Re: [openstack-dev] [swift] Stategy to port Swift to Python 3

Hi, I'll be helping out victor too on the changes , and will try to do as much as possible on it. :) On Tue, Jul 7, 2015 at 11:12 PM, John Dickinson wrote: > Victor, > > Thank you for working on this. Please don't give up on this work! I'll be > asking others to look at these patches, and I'

Re: [openstack-dev] [swift] Stategy to port Swift to Python 3

Victor, Thank you for working on this. Please don't give up on this work! I'll be asking others to look at these patches, and I'll try to look, myself, soon. For the dependencies (pyeclib), we'll get those as we can. The first priority is getting the Swift code, which we control, squared away.

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

Excerpts from Steven Dake (stdake)'s message of 2015-07-03 11:53:00 -0700: > Kolla Devs as well as the Technical Committee, > > I wanted to get the TC’s thoughts on this plan of action as we intend to > apply for big tent once our Ansible code has completed implementation. If > the approach out

[openstack-dev] [Ironic] weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Oslo (lintan) = initial (unstable-API) releases for oslo.cache, oslo.reports, oslo.service, automaton, futurist are in pypi - oslo.service and automation is alrea

Re: [openstack-dev] [horizon] Modifying existing dashboards with plugins

Right, this was the suggestion I also recommended in IRC. The only issue here is if/when another plugin attempt to extend from the same panel, then we'd run into conflicts that would require manual resolution (but I'm not sure there is any other way around this).-Lin Hua Cheng wrote: -To:

[openstack-dev] [Nova] Friday July 10 is Nova's "non-priority feature review bash day"

Hi, Friday is: non-priority feature review bash day https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Dates_overview The idea is the whole nova community is invited to concentrate on reviewing some some of the low priority blueprints that have been hanging around for a while. *Note*

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

HEAD, head, 24f28869838b (my new file) all say the same thing. :( On Tue, Jul 7, 2015 at 12:34 PM Salvatore Orlando wrote: > possibly I was wrong in mixing up git & alembic. > It should be "upgrade head" - lowercase. > > If that doesn't work there might some other issue lurking. > > Salvatore >

[openstack-dev] Build dependency loop: python-os-client-config and python-oslotest

Hi, It seems that the above packages are build-depending on each other. We need this kind of thing to be broken. Can something be done? Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage ques

Re: [openstack-dev] [horizon] Modifying existing dashboards with plugins

This was discussed two summits ago, I believe the preferred way to modify the tables was to extend the panel classes, do your customization there, and use the plugin mechanism to turn off the original panel and add the newly extended panel. It is not straight-forward, but it will be have less risk

Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

Team, Thanks everyone for your input on this thread. To make a decision, I’d like input form Lars. I have put this on our team meeting agenda for next Tuesday (2015-07-14 2200 UTC in #openstack-meeting-alt). I’ll reach out to him on IRC and ask if he can make time to attend. If Magnum feels co

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

http://afe.easia.columbia.edu/main_pop/kpct/kp_meiji.htm There's a summary of what Meiji might mean to historians. I'm not sure if OpenStack needs to be too concerned about this, but I believe this is what Ian is referring to as "historical and political debates in East Asia." Seems like a hot-bu

[openstack-dev] [cloudpulse][release] Announcing Cloudpulse Liberty-1 Release

Hi, We are pleased to announce the rock'in release of the CloudPulse Liberty 1 milestone. In this milestone our community implemented 5 blueprints! Our individual review contributors were: http://stackalytics.com/?project_type=all&module=cloudpulse This release includes the following featur

Re: [openstack-dev] [oslo] Document API changes using Sphinx markups

fwiw - openstackclient has been using .. versionadded:: in it's docs for a while: http://docs.openstack.org/developer/python-openstackclient/_sources/command-objects/user.txt Thanks, Steve Martinelli OpenStack Keystone Core From: Victor Stinner To: OpenStack List Date: 2015/07/07 11

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

Excerpts from Mehdi Abaakouk's message of 2015-07-07 04:07:51 -0700: > Hi, > > The RPC API of oslo.messaging do it for you, you don't have to care > about acknowledgement (or anything else done by the driver because the > underlying used pattern depends of it) . > The original poster wasn't a

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

I like the idea. When writing release notes, the more information we have the better. I usually look at the blueprints that were completed or our specs, but having an additional source (a commit message I could query) is always good. Thanks, Steve Martinelli OpenStack Keystone Core From: Ma

Re: [openstack-dev] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?

On 07/04/2015 12:12 AM, Akihiro Motoki wrote: > Hi Oslo and Neutron folks, > > Why is policy_dirs option deprecated in oslo.policy? > In Neutron we have multiple repositories which consist of Neutron services > and we would like to maintain policy.json separately. > policy_dirs option looks useful

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

possibly I was wrong in mixing up git & alembic. It should be "upgrade head" - lowercase. If that doesn't work there might some other issue lurking. Salvatore On 7 July 2015 at 17:44, Paul Michali wrote: > Salvatore, > > I changed head to the version before my new one, and then tried to upgrad

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

> The thing is, UpgradeImpact isn't always appropriate for the change, but > DocImpact is used too broadly and as far as I can tell, it's not really > for updating release notes [2]. It's for updating stuff found in > docs.openstack.org. > > So we kicked around the idea of a ReleaseNoteImpact tag

[openstack-dev] [python-openstacksdk] Moratorium on services, features until post-1.0

In the interest of moving towards a 1.0 release of OpenStack SDK, we're going to halt accepting any new resources on existing services, and any entirely new services. After release, we'll open back up and both deepen and broaden our support for other OpenStack services. We currently have a backlog

Re: [openstack-dev] [oslo] Document API changes using Sphinx markups

Le 07/07/2015 18:13, Clint Byrum a écrit : Any time we have versions appearing in code or docs, I cringe, because versions and releasing are separate from coding and documenting. If I'm adding a parameter today in the latest commit after 1.0.0, I really don't know if the next version released wil

Re: [openstack-dev] [oslo] Document API changes using Sphinx markups

Excerpts from Victor Stinner's message of 2015-07-07 08:22:26 -0700: > Hi, > > Oslo libraries become more and more stable, cool :-) Sometimes, we have > to modify APIs, to fix bugs, to deprecate functions, to add new function > parameters, etc. It would be cool to _document_ these changes. Sphin

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

While reviewing a change in nova [1] I mentioned that we should have something in the release notes for Liberty on the change. Typically for this I ask that the UpgradeImpact tag is added to the commit message because at the end of a release I search git/gerrit for any commits that have Upgrad

Re: [openstack-dev] [neutron] Breakage by commit 18bc67d56faef30a0f73429a5ee580e052858cb5

Hi Paul, Let me look into it. Thanks, Armando On 7 July 2015 at 08:51, Paul Michali wrote: > I'm seeing that neutron-vpn repo py27 tests are now failing. Did a git > bisect in Neutron and found that this commit is causing the failure (not > sure what's broken). > > commit 18bc67d56faef30a0f734

Re: [openstack-dev] [Murano][Congress] Application placement use case

Hi Nikolay, I am not sure about that. I mentioned it because bellow described usecase could be argument to continue work on that. Filip On 07/07/2015 05:29 PM, Nikolay Starodubtsev wrote: Filip, Are you sure that this bp is still alive? Looks like the spec was freezed a month ago and develo

Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging

> On 07 Jul 2015, at 17:07, Mehdi Abaakouk wrote: > > The RPC API of oslo.messaging do it for you, you don't have to care about > acknowledgement (or anything else done by the driver because the underlying > used pattern depends of it) . Phrases like this really scare me. Sorry :) As a devel

[openstack-dev] [nova] Nova Liberty Midcyle agenda

Hi, It would be great to start writing down ideas of what you want to discuss at the midcycle: https://etherpad.openstack.org/p/liberty-nova-midcycle I have also added a draft agenda, but we will discuss and decide that details on the day, in the usual un-conference style. For more details about

[openstack-dev] [neutron] Breakage by commit 18bc67d56faef30a0f73429a5ee580e052858cb5

I'm seeing that neutron-vpn repo py27 tests are now failing. Did a git bisect in Neutron and found that this commit is causing the failure (not sure what's broken). commit 18bc67d56faef30a0f73429a5ee580e052858cb5 Author: armando-migliaccio Date: Thu Jul 2 12:56:24 2015 -0700 COMMON_PREFIXE

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

Salvatore, I changed head to the version before my new one, and then tried to upgrade and I see this: neutron-db-manage --config-file /opt/stack/neutron/etc/neutron.conf --service vpnaas upgrade HEAD Traceback (most recent call last): File "/usr/local/bin/neutron-db-manage", line 10, in sy

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

At this time, there is no hard requirement on using AngularJS for Horizon plugins. Existing plugins should not feel pressured to rewrite. Support for Django content is not going away anytime soon. The Horizon team feels that long term AngularJS will prove to be a better framework to build on. But w

Re: [openstack-dev] [puppet] weekly meeting #41

On 07/06/2015 08:32 AM, Emilien Macchi wrote: > Hey Puppeteers! > > Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150707 > > Please add a

Re: [openstack-dev] [Nova] Deadline for mid-cycle meetup signup

On 25 June 2015 at 23:57, Michael Still wrote: > Hi, > > I just wanted to let people know that we're setting a deadline of 7 > July for mid-cycle meetup signups. So, if you're intending to sign up > but haven't already I'd do it real soon now. Just a quick nudge to say that the deadline is today

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

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 is little in the way of code examples; launch instance, which last I checked has a few major bugs, the unfinished (?) identity dashboard and a few metadata modals

Re: [openstack-dev] [Murano][Congress] Application placement use case

Filip, Are you sure that this bp is still alive? Looks like the spec was freezed a month ago and development wasn't started. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-07-07 17:47 GMT+03:00 vemana Kanaka Durgarao : > vemana.kanakadurga...@gmail.com >

Re: [openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium

After some consultation with Doug and Thierry, we've boiled the change I'm recommending below down to two options: 1. independent, ad-hoc backport branches, tag yourself 2. cycle-with-intermediary, stable branches, tag by RelMgt team I think what we really want is option #1 for these projects. I'

Re: [openstack-dev] [horizon] Modifying existing dashboards with plugins

AFAIK, the customisation is mainly restricted to panels and dashboards and styling, as Matthias said. I¹ll be looking into extending the workflows shortly. If you have any ideas on implementation, feel free to suggest. Rob On 07/07/2015 11:00, "Matthias Runge" wrote: >On Mon, Jul 06, 2015 at 0

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

Thanks, Kevin, but I believe we're already doing what you advise; please see https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348 Is there a way of checking that there aren't still any open transactions, when update_port_postcommit is called? Thanks,

[openstack-dev] [Fuel][Plugins] generators support in environment_config.yaml for plugins

Hi, colleagues Is it possible to generate random value for field (actually field with type: password) in environment_config.yaml I'm trying something like https://github.com/stackforge/fuel-web/blob/stable/6.1/nailgun/nailgun/fixtures/openstack.yaml#L836 but seems it doesn't work Thanks -- Serg

[openstack-dev] [oslo] Document API changes using Sphinx markups

Hi, Oslo libraries become more and more stable, cool :-) Sometimes, we have to modify APIs, to fix bugs, to deprecate functions, to add new function parameters, etc. It would be cool to _document_ these changes. Sphinx provides nice markups to document API changes: http://sphinx-doc.org/m

[openstack-dev] [neutron] New time and channel for neutron-drivers team weekly meeting

I've updated the time for this meeting [1] and added it to the wiki [2]. The new meeting logistics are as follows: Time: 1500 UTC Channel: #openstack-meeting We'll skip this week and resume the meetings next week. Thanks! Kyle [1] https://review.openstack.org/#/c/198806/ [2] https://wiki.openst

Re: [openstack-dev] Should project name be uppercase or lowercase?

On 7 July 2015 at 15:44, Jeremy Stanley wrote: > On 2015-07-07 13:24:00 +0100 (+0100), Dave Walker wrote: > [...] >> I am interested to hear why the convention in documentation for it to >> be lower case. > [...] > > Seems like this question comes up once for every two or three new > writers/edito

[openstack-dev] [QA] Doodle poll for New Alternating Week QA Meeting time

Hi everyone, As a follow-up from the QA meeting from 2 weeks ago I'm starting a poll to reschedule the 22:00 UTC QA meeting: http://doodle.com/eykyptgi3ca3r9mk I used the yaml2ical repo (which is awesome and makes this so much easier) to figure out which slots were open for Thursday. To summar

Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support

Ok, I see that now, too. I’m confused why the default is still 60 in olso.messaging 1.9.0 and 1.10.0 though? I confess I don’t completely understand the versioning here. But if we are saying that the default for Kilo will be and is 0, then I’m happy setting that as the default in the Puppet m

  1   2   >